As it is generally known, electronic mail (“email”) software systems transmit messages and associated document attachments between computer system users over a communication network. Email systems are often architected in a client-server software model, in which client software is provided in end user computer systems to enable users to compose, send and receive messages, while a server software component is provided to perform various centralized functions. In most email systems, messages can be received on behalf of a user by a server computer system for later retrieval. For example, an email client application program on a local computer system may operate by periodically querying an associated email server system to determine if one or more new messages have arrived for a local user. If so, then the email client can provide an alert to the local user indicating the arrival of the new message or messages. The local user can then download the received messages from the server system to the local client computer system. Email requires an underlying messaging system, which provides a store and forward capability, such as the Internet's Simple Mail Transfer Protocol (SMTP). Well known existing email client systems include Microsoft®'s Outlook and Eudora®. The Web browser program may also used to provide the mail client by way of an Internet email service, such as services provided by Google, Yahoo, and other Web portal providers.
Typical email applications provide a user with a graphical user interface through which messages can be composed and sent, and through which received and previously sent messages can be viewed. A number of mailbox constructs are usually maintained for the user, including an Inbox to store received messages, an Outbox into which messages are put pending being sent, and a Sent mailbox for storing messages that have previously been transmitted. An email message usually includes or is associated with one or more destination addresses or user names identifying recipients to which the message is to be delivered, sometimes known as a “To:” field. A “From:” field is also included or associated with a message, and identifies the sender of the message. A “Subject:” field for an email message includes a text string defining the subject of the message. A message body stores the content of the message, including text, images, links, or other content. A number of separate documents may also be attached to a message before it is sent, containing additional content to that contained-within the message body. After the message body, destination email addresses, and any attachments to the message are defined by the user, a “Send” graphical button or the like can be clicked on or otherwise selected in order to cause the message to be sent.
When a message is received, the email client software provides a receiving user with the ability to reply to the received message, for example by way of a “Reply” and/or “Reply All” button within the graphical user interface. Clicking on the “Reply” button sets up a new message, including the received message, for editing and sending back to the original sender of the received message. Clicking on the “Reply All” button also sets up a new message, also including the received message, for editing and sending back to the original sender and any other recipients of the original message. A reply that is sent including all previous message information is sometimes referred to as a “reply with history”. The original sender, or any other recipient of a reply message, may then similarly generate another reply.
A series of received messages that are direct or indirect replies to an original “root” message may be referred to as a message “thread”. The reply messages in a thread may be considered child messages under the original root message. In addition to the reply messages, a thread may or may not be considered to also include the original root message. In an email system, a thread may consist of a number of related received messages stored in a user's Inbox, or another mailbox structure provided by the email system.
Some existing email systems have attempted to display message threads in a user friendly way by using what are referred to as “gathered” threads views. For example, in one type of gathered threads view, received messages belonging to a thread are represented using a single message entry in the user's Inbox. However, not all email users have such a view available to them, or prefer such a view, and accordingly “non-gathered” views remain common.
A problem with existing email systems occurs when a user accesses different versions of a document attachment, as may occur when an attachment is modified within a message thread. Email threads are often used to share document attachments among multiple users, such as during a review process for a specification document. Such a process may involve several iterations in which the document being reviewed is sent back and forth with different modifications. In existing systems, when an Inbox or Folder view is used that doesn't gather a thread through a gathered threads view, it may be difficult to find the most recently sent or received message in the thread, and even more difficult to find the latest version of an attached document sent back and forth within the thread. For example, if a user simply opens an email message without knowing if that message is the last message in the thread, the user may not be able to easily determine whether the document attached to that message is the most recent version of the document with regard to modifications made within the thread. This situation relates to the fact that many existing email systems attach a document to a message by carrying the document within the message, and allow modifications to the document attachment within the message.
For these reasons and others, it would be desirable to have a new system for handling email messages that enables a user to open any message in an email message thread and conveniently obtain a most recent version of any document attached to the message. The system should be operable to provide a most recent version of an attached document regardless of which message within the tread that the user has opened, including when the opened message is not the most recent message in the thread. Moreover, the new system should enable the user to alternatively open the version of the document that was originally attached to the opened message, even if that version is not the most recent version of the document.